A typical enterprise computing environment includes multiple heterogeneous and distributed databases supporting a variety of different enterprise organizations and systems. For example, many enterprises such as businesses and the like maintain different databases to support customer billing, sales, accounting, marketing, inventory, ordering, repairs, procurement, etc. Further, many enterprises are the result of a merger of two or more predecessors, each with their own set of heterogeneous, and distributed databases.
Common data is typically stored in some or all of the databases of an enterprise. However, the common data is often used for different business purposes and/or defined according to different local schemas (e.g., defined in different formats, according to different technologies, according to different data models, or according to different business rules). For example, different enterprise databases may use different local schemas to represent a customer and/or accounts associated with the customer. In addition, because enterprise databases often serve different business purposes, the relationships between customers and accounts may vary and/or be defined differently across the enterprise databases.
The diversity of an enterprise's databases creates challenges for the enterprise. For example, disparities between the local schemas employed by enterprise databases make it difficult, and often impossible, to ensure that data representing the same customers and accounts is created, maintained, and updated uniformly across all systems within the enterprise. The difficulty is increased when the enterprise systems include legacy databases that are limited in functionality as compared to more up-to-date database technologies.
The diversity of an enterprise's databases also places technical limitations on the ability of the enterprise to provide information and functionality to its customers. For example, a particular customer may desire to organize and view account information in a particular way that is not supported by the diverse databases in the enterprise. By way of one example, for a customer that includes multiple entities (e.g., subsidiaries), an enterprise billing system may organize customer data (e.g., customer account information) according to the legal relationships between the entities of the customer, but the customer may wish to view its account information according to a different organizational structure, such as by geographical region or by size of branch locations. A typical legacy database is unable to maintain its organizational data structure and fulfill a request for data organized according to a different structure. Accordingly, conventional enterprise computing environments may allow customers to access account information organized in a particular way, but the customers are unable to re-organize the account information.
Disparities between enterprise databases may also make it difficult to fulfill customer requests to view account information organized in a way that requires data to be retrieved from more than one enterprise database, especially when the enterprise databases from which the data will be retrieved employ different organizational structures than the organizational structure requested by the customer. Accordingly, customers may be unable to manage their accounts as they desire or as will best serve their business purposes. Such situations are especially common and problematic for enterprise-level customers that have complicated business structures and purposes.
Currently, enterprises may expend considerable resources to manually create custom organizations and views of data desired by customers. Typically, one or more employees of an enterprise spends significant time manually gathering data from the diverse enterprise databases and organizing the data according to the organizational structures requested by customers. However, such a solution quickly becomes impractical for a large enterprise maintaining significant amounts of data and/or when considerable numbers of different organization data structures and views are requested by customers.
Despite the foregoing difficulties associated with an enterprise operating diverse databases, there are many reasons why multiple heterogeneous and independent databases may exist within an enterprise. Where databases were created using different technologies or different data models, there may be considerable disruption to the enterprise, not to mention considerable time and expense, in migrating the multiple databases to the same technology platform. Accordingly, in many cases it is simply impossible, or at least impractical, for an enterprise to integrate its multiple heterogeneous and independent databases. Further, the risk of committing the entire enterprise to a single technology platform is unacceptable to many enterprises, given the possibilities that, for a given technology platform, vendors may go out of business, properly experienced staff may be unavailable, the technology may not prove to be robust or adequate to the needs of the enterprise, etc. Moreover, from the standpoint of resisting and recovering from disasters, it is advantageous for an enterprise to have multiple databases that are widely dispersed geographically and/or in terms of technology platforms, business units, etc.
Accordingly, there is a need for systems and methods that provide customers with one or more tools for managing data, including defining custom hierarchical structures of data without impacting or being limited by the internal requirements of diverse databases.